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1.0  Executive  Summary 
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Marble  Associates,  Inc.,  is  engaged  in  the  development  of  customizable  menus  in 
NEXTSTEP  and  the  X  windowing  environment.  In  this  document,  we  present  the 
design  and  implementation  path  for  realizing  end-user  customizable  menus  in  X  and 
Motif. 

The  differences  between  the  NEXTSTEP  and  X  development  environments  motivate 
an  approach  to  bringing  customizable  menus  to  X  and  Motif  that  differs  from  our 
approach  in  NEXTSTEP.  Initially,  we  intend  to  provide  the  basic  functionality  of  cus¬ 
tomizing  menus  via  modal  dialog  boxes,  and  we  will  investigate  the  feasibility  of  pro¬ 
viding  the  same  functionality  through  drag  and  drop  (DND)  in  later  stages  of  our 
implementation  path. 

We  do  not  foresee  any  difficulties  in  the  initial  stage  of  our  implementation.  However, 
the  success  of  our  DND  effort  is  contingent  on  the  flexibility  of  Motif.  Specifically, 
though  “subclassing”  widgets  is  a  known  process,  we  must  determine  any  loss  of  func¬ 
tionality  in  the  Motif  widget  set  when  we  add  functionalities  to  an  existing  widget 
through  this  “subclassing”  mechanism. 


This  rest  of  this  paper  is  organized  as  follows. 

•  Background — ^This  section  provides  a  brief  discussion  of  our  work  in  realiz¬ 
ing  the  Command  Editor  for  NEXTSTEP. 

•  Functional  Specification — ^This  section  introduces  the  functionalities  we 
intend  to  provide  to  the  end-user  and  the  interface  we  will  present  to  the  devel¬ 
oper. 

■  Constraints — ^Tbis  section  discusses  the  inner  wtu-kings  of  the  X  window 

system  and  Motif.  Specifically,  it  focuses  on  the  challenges  we  face  in  realiz¬ 
ing  the  functionalities  presented  in  the  previous  section. 

•  Implementation  Path — ^This  section  presents  the  process  by  which  we  can 
realize  the  desired  functionalities  in  the  face  of  system  constraints.  The  pro¬ 
cess  is  divided  into  stages  that  represent  the  evolution  of  our  product  from  a 
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minimal  implementation  based  on  Motif  dialog  boxes  to  one  that  employs 
DND. 

•  Questions  and  Impact — ^This  section  discusses  the  critical  issues  that  will 
affect  the  implementation  path. 

•  Related  Documents — ^Tbis  section  lists  the  other  documents  submitted  under 
Contract  #  DAAH01-93-C-R013. 

•  Sources — ^This  section  lists  the  sources  used  in  our  research. 

Many  of  the  terms  and  concepts  in  this  document  originate  from  the  NEXTSTEP 
implementation  of  the  Command  Editor.  Subsequent  discussions  assume  that  the 
reader  is  ^miliar  with  the  documents  listed  in  the  “Related  Documents”  section  and 
has  a  general  understanding  of  X  and  Motif.  Despite  the  similarities  in  concepts  and 
goals,  the  implementations  differ  vastly,  and  we  will  introduce  new  terminology  and 
new  names  for  this  implementaticm  to  prevent  any  confusion  and  inappropriate  analo¬ 
gies. 


2.0  Background 

Our  Phase  I  proposal  drew  inspiration  from  a  Microsoft  Windows  application  that  pro¬ 
vided  a  customizable  menu  bar;  we  thus  focus  on  bringing  this  functionality  to  NEXT¬ 
STEP,  with  the  intention  that  we  would  do  likewise  for  the  X  environment. 

The  rich  toolset  of  the  NEXTSTEP  development  environment  facilitates  efficient  reuse 
of  existing  functionalities  .uid  quick  prototyping  of  a  graphical  interface  on  behalf  of 
the  developer.  Through  Objective-C,  the  native  language  of  NEXTSTEP,  the  developer 
can  easily  subclass  complex  objects  and  inherit  their  functionalities  with  a  few  lines  of 
code.  Through  Interface  Bui'der  (IB),  the  developer  can  construct  a  graphical  interface 
to  his  application  by  dragging  and  dropping  objects  from  “palettes”  onto  a  canvas. 
Through  tools  integrated  into  IB,  the  developer  can  integrate  the  interface  with  the  ap¬ 
plication  logic. 

In  addition  to  these  conveniences,  the  NEXTSTEP  development  environment  is  extend¬ 
able,  providing  a  process  through  which  tool  builders  can  easily  integrate  customized 
objects  into  IB  known  as  “paletting.”  This  integration,  in  turn,  provides  new  functional¬ 
ities  to  the  developer  in  a  manner  keeping  with  the  IB  interface  construction  mecha¬ 
nism:  the  user  can  drag  and  drop  the  customized  objects  onto  his  canvas  as  if  they 
were  default  system  objects. 

The  Command  Editor  for  NEXTSTEP  provides  customizable  menus  to  the  developer 
through  IB,  making  use  of  the  convenient  “paletting”  process.  We  construct  the  Com¬ 
mand  Editor  itself  using  the  subclassing  methodology  to  bring  new  functionalities  to 
existing  system  classes  while  retaining  inherited  capabilities. 

By  contrast,  the  X  development  environment  lacks  many  of  these  convenient  mecha¬ 
nisms.  Bringing  new  functionalities  to  an  existing  widget  type  in  X,  also  termed  “sub¬ 
classing”  a  widget,  entails  rewriting  that  widget.  This  could  encompass  hundreds  of 
lines  of  code  and  is  necessary  since  the  native  language  of  X  is  C.  Furthermore,  X 
lacks  a  standard  development  methodology  that  would  allow  us  to  present  the  Com¬ 
mand  Editor  in  a  packaged  form.  Any  toolset  for  the  X  environment,  typically  consist- 
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ing  of  modified  system  widgets,  pro'.idcs  to  the  develtqter  the  full  source  listing  for 
that  widget  set. 

The  impact  this  has  on  our  effort  is  two-fdd.  Fast,  we  cannot  taiget  the  same  level  cf 
functionality  for  the  Command  Editor  here  as  we  did  for  NEXTSTEP.  Second,  we  can 
only  provide  the  final  product  as  complete  source  code.  Though  we  will  provide  exam¬ 
ples,  the  process  of  integrating  our  components  into  the  api^ication  is  left  coraplelely 
up  to  the  developer. 


% 
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3.0  Functional  Specification 


Our  objective  is  to  provide  to  the  developer  a  mechanism  by  whidi  he  can  integrate 
customizable  menus  into  his  Motif  application.  This  mechanism  allows  die  end-user  to 
customize  the  application’s  menu  system  at  runtime.  The  implementation  path  for  the 
Command  Editor  divides  our  development  effort  into  two  stages  defined  by  the  func¬ 
tionality  it  brings  to  the  user.  We  discuss  the  functional  differences  between  the  two 
stages  from  the  perspectives  of  the  user  and  developer  in  the  following  sections. 

3.1  Eiid-user  Functionality 

The  functionality  targeted  in  the  initial  developmem  stage  allows  the  end-user  to  do 
the  following  at  runtime: 

•  rename,  add,  and  remove  menu  items  from  a  Motif  menu  curtain; 

•  specify  accelerator  keys  and  iiuiemonics  for  a  menu  item; 

•  add  and  populate  submenus;  and 

•  load  Motif  buttons  with  iconic  representations  of  menu  items. 

A  series  of  Motif  dialog  boxes  will  facilitate  these  functions.  The  user  selects  the 
“Menu”  item  from  the  Xustonuze”  cascade  button  in  the  menu  bar  and  brings  forth 
the  CEMenuConfigurator  (Figiue  1).  This  selection  dialog  box  contains  a  hierarchi¬ 
cal  list  of  menu  items  representing  the  current  configuration  of  the  apjtiication  menu 
system.  The  user  then  selects  an  entry  from  the  browser  and  specifies  its  mnemonic 
and  accelerator  key.  Entries  desi^ated  as  “default”  by  the  developer  are  not  customiz¬ 
able  and  will  be  “grayed  out”  by  the  CEMenuConfigurator.  The  user  can  also 
remove  the  menu  item  or  add  a  new  menu  item  under  the  selection.  Selecting  “Add” 
will  activate  the  CECommandBrowser,  a  selection  dialog  box  that  displays  a  hietv- 
chical  listing  of  the  full  set  of  commatxls  configured  by  the  developer  (Hgute  2).  The 
user  can  now  peruse  the  set  of  commands  available  and  select  the  additional  menu 
item. 

The  user  can  similarly  add  a  cascaded  menu  curtain  by  selecting  the  “Submenu” 
button,  which  activates  a  popup  dialog  box  that  comains  a  text  entry  field,  allowing  the 
user  to  enter  the  submenu  title.  The  user  can  populate  the  submenu  via  the  “Pt^aie- 
Submenu”  button. 
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The  CEMenuConfigurator  in  Motif:  An  Approximation 


RGURE  2  The  CECommandBrowser  in  Motif:  An  Approximation 


To  configure  the  CECommandToolButtons  provided  by  the  developer,  the  user 
selects  ‘Tools”  from  the  "Customize”  cascade  button  in  the  menu  bar.  This  selection 
changes  the  cursor  to  a  “Customize  Tools”  cursor,  indicative  of  the  special  mode  the 
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user  has  just  entered  (Figure  3).  Tlie  user  then  selects  a  CECommandToolButton 
with  the  mouse  and,  in  doing  so,  activates  a  dialog  that  allows  the  specification  of  a 
menu  command  that  button  is  to  trigger.  The  CECommandlbolButton  now  displays 
the  icon  associated  with  the  selected  menu  command. 

The  second  stage  of  our  developnrent  cycle  will  {mrvide  DND  functionality  to  the  end- 
user.  The  user  can  now  configure  the  menu  system  by  dragging  a  menu  item  from  the 
CECommandBrowser  onto  the  CEMenuConfigurator  (Figure  4).  The  user  will  cus¬ 
tomize  CECommandTbolButtons  in  similar  fashion — by  dragging  a  menu  item  from 
the  CECommandBrowser  onto  a  CECommandlbolButton  (Figure  S). 


FIGURE  3 
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3.2  Developer  Interface 

The  Command  Editor  in  X  and  Motif  provides  a  framework  in  which  the  developer  uti¬ 
lizes  our  components  to  facilitate  customizable  menus.  This  framework  consists  of 
source  modules  and  guidelines  that,  together,  dictate  specific  methods  the  developer 
must  employ.  This  organization  results  directly  from  the  lack  of  a  standard  develop¬ 
ment  environment  for  the  X  and  Motif  community.  We  simply  cannot  provide  the  Com¬ 
mand  Editor  as  a  custom  palette  in  a  particular  interface  building  tool;  doing  so  would 
require  the  developer  to  purchase  additional  software.  Any  loss  of  flexibility  on  behalf 
of  the  developer  results  from  the  constraints  of  the  X  window  system  and  Motif. 

In  contrast,  NEXTSTEP  provides  the  developer  with  a  uniform  methodology  for  writ¬ 
ing  graphical  applications.  This  methodology  is  the  framewoik  presented  by  Interface 
Builder,  which  is  included  in  every  installation  of  NEXTSTEP.  This  provision,  in  turn, 
allows  tool  developers  to  provide  to  application  developers  new  functionalities.  These 
new  functionalities  are  packaged  in  a  manner  that  facilitates  ease  of  integration — 
through  IB  itself 

The  CECommandBrowser  and  CEMenuConfigurator  are  special  purpose  Motif  dia¬ 
logs  that  the  developer  must  integrate  into  his  application  code.  Example  code  will  be 
provided  to  illustrate  this  integration. 

The  developer  must  create  menus  through  a  prescribed  interface.  Though  the  resulting 
menus  will  be  standard  Motif  Widgets,  the  configuration  data  must  be  maintained  by  a 
module  in  the  Command  Editor,  and  the  standard  Motif  method  of  creating  menus  is 
no  longer  available  to  the  developer  should  he  desire  customizable  menus.  The  devel¬ 
oper  fills  in  a  CEMenuCell  structure  with  customizing  parameters  (default,  config¬ 
urable,  icon,  description,  etc.)  in  addition  to  standard  Motif  information  (title, 
accelerator  key,  mnemonic,  and  callback).  This  CEMenuCell  can  then  be  loaded  into 
the  Command  Editor  through  an  CEAddMenuIfem  call.  Parameters  to  this  call  reveal 
the  placement  of  the  new  CEMenuCell  in  the  menu  hierarchy.  The  developer  employs 
this  menu  creation  process  to  compose  the  full  set  of  available  commands  as  well  as  to 
configure  the  default  application  menu  system. 

Once  the  appropriate  components  are  developed,  we  intend  to  provide  a  Motif  tool  that 
allows  the  developer  to  compose  the  hierarchical  menu  system  visually.  The  developer 
can  specify  menu  item  order,  titles,  mnemonics,  accelerator  keys,  and  submenu  topolo¬ 
gy.  Callbacks  and  icons  associated  with  each  menu  item  will  be  stubbed  out  for  the  de¬ 
veloper  to  fill  in  later.  The  resulting  configuration  will  be  formatted  such  that  the 
developer  can  integrate  the  menus  into  the  application.  This  facility  will  be  used  to  con¬ 
figure  both  the  application  menu  and  the  full  set  of  commands  available  for  customiza¬ 
tion. 

The  CECommandToolButtons  necessitate  a  separate  mechanism  to  allow  the  devel¬ 
oper  to  place  them  anywhere  in  the  application  and  to  enable  customization  by  the  end- 
user  at  runtime.  The  developer  creates  a  CECommandToolButton  as  a  standard  Motif 
PushButton.  The  developer  configures  CECommandToolButtons  in  the  standard  Mo¬ 
tif  way — setting  the  widget’s  resources  explicitly  to  determine  the  label  or  pixmap  dis¬ 
played  and  the  callback  procedure  that  the  button  invokes.  To  capture  the  customiza¬ 
tion  capability,  the  developer  must  register  the  resulting  Motif  widget  with  the 
Command  Editor. 
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The  second  stage  of  our  development  will  not  modify  the  interface  to  the  developer. 
Composition  of  the  full  set  of  commands  available  to  the  end-user  and  configuration  of 
the  initial  menu  system  will  adhere  to  the  methods  detailed  in  the  previous  discussions. 


4.0  Constraints 

From  the  developer’s  perspective,  die  X  window  system  consists  of  two  layers  of  librar¬ 
ies;  Xlib  and  Xt  While  the  routines  in  the  Xlib  layer  handle  the  low  level  duties  required 
to  display  windows  on  a  screen,  the  calls  in  Xt  provide  a  measure  of  abstraction  for  the 
developer.  Xt  packages  many  of  the  sequences  of  Xlib  calls  that  typify  an  X  application 
into  convenience  functions.  In  addition,  Xt  provides  Widgets  (screen  elements)  such  as 
buttons,  scrollbars,  and  forms  that  are  useful  to  a  developer.  Motif  and  Open  Look  are 
additional  layers  that  enforce  a  particular  interface  style  (the  placement  of  menus,  but¬ 
tons,  and  scrollbars  in  an  application)  and  furnish  their  own  set  of  convenience  functions 
to  implement  those  styles.  The  motivation  for  conforming  to  a  particular  interface  style 
is  acceptance  of  the  application  by  users  of  that  style.  An  additional  motivation  for  work¬ 
ing  above  the  Motif  and  Open  Lode  layers  is  the  availability  of  convenience  functions 
that  not  only  implement  the  particular  style  but  also  save  the  developer  from  reams  of  Xt 
code  necessary  to  produce  functionally  equivalent  visual  elements  (menus,  text  widgets, 
etc.).  We  focus  our  efforts  at  this  tc^  layer  and  will  develop  in  Motif,  since  Motif  is  by 
far  the  most  widely  accepted  interface  style  in  the  Unix  conununity,  undoubtedly  outpac¬ 
ing  Open  Look  in  user  acceptance  and  number  of  conforming  products. 

4.1  The  X  Development  Environment 

The  lack  of  object-oriented  technology  in  X  (and  consequently  MotiO  poses  serious 
constraints  on  our  development  effort.  The  layered  architecture  of  X,  which  affords  it 
portability  and  remote  display  capability,  is  not  abstracted  from  a  developer’s  point  of 
view.  Indeed,  Motif  applications  are  allowed  to  make  calls  to  all  layers  of  the  X  envi¬ 
ronment.  These  applications  are  “Motif”  only  in  look — using  resources  defined  in  the 
Motif  libraries  that  define  this  look.  Motif  calls  simply  map  to  Xt  calls. 

This  allowance  violates  the  basic  tenets  of  objea-oriented  development.  The  dependen¬ 
cy  between  the  application  layer  on  all  layers  of  the  X  and  Motif  environment  inhibits 
reuse.  For  instance,  X  lacks  a  generic  hierarchical  display  widget  that  allows  the  user 
to  traverse  and  select  items  from  a  tree.  Development  of  such  a  widget  will  be  specific 
to  the  data  type  of  the  ruxles.  There  is  no  concept  of  messaging  objects  in  X.  The  lack 
of  this  capability  dictates  that  the  hierarchical  display  widget  knows  the  type  of  the 
data  node  explicitly  in  order  to  (I)  display  the  text  label  of  the  node  and  (2)  traverse 
the  tree.The  Motif  FileSelectionDialog  widget,  for  instance,  is  closely  tied  to  the  Unix 
file  system  and  cannot  be  customized  to  display  any  other  hierarchy. 

One  key  contributor  to  the  lack  of  object-oriented  design  of  X  is  the  C  progranuning 
language  it.<ielf — through  which  X  presents  itself.  Objects  do  not  truly  exist  in  the  X  en¬ 
vironment  in  that  they  cannot  be  sent  messages.  The  application  simply  links  in  library 
calls  to  the  underlying  layers.  “Objea  instantiation”  entails  the  processing  of  all  li¬ 
brary  calls  that  allocate  memory  for  the  data  structure  and  sets  its  resources.  “Subclass¬ 
ing”  a  widget  entails  copying  the  widget’s  definition  files  and  modifying  its  resource 
values.  The  term  “subclassing  a  widget”  is  synonymous  with  rewriting  a  widget,  where 
the  developer  must  provide  extensive  code  to  do  all  of  the  following: 
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•  modify  the  widget’s  resource  list,  effectively  adding  instance  data; 

•  imi^eiiient  the  initialization  procedure  to  set  instance  data; 


•  implement  the  drawing  procedures  to  resize  and  expose  the  screen  element; 
and 


•  implemei:t  all  widget  specific  actions  that  are  performed  given  some  user  in¬ 
put 

This  replication  of  code,  even  by  include  files,  is  not  efficient  reuse.  Furthermore,  the 
term  “subclass”  implies  inheritance  in  object-oriented  technologies,  whereby  sub¬ 
classed  objects  obtain  functionalities  of  their  parent  class.  Copying  definition  files  of  X 
widgets  allow  the  functionalities  to  replicated  in  any  new  widget.  The  availability  of 
the  same  capability  in  Motif  is  unclear.  For  instance,  the  Motif  implementation  of 
menus  is  private,  and  subclassing  the  components  of  a  Motif  menu  may  compromise 
functionality.  In  short,  subclassing  does  not  necessarily  imply  inheritance  in  Motif 

By  contrast,  the  object-oriented  design  of  NEXTSTEP  and  even  SmallTalk  affords  the 
developer  the  capability  to  augment  existing  system  objects  rapidly  with  inheritance  of 
functionality.  Many  of  these  system  objects  correspond  to  widgets,  providing  a  graphi¬ 
cal  interface  and  handling  user  input.  In  addition,  subclassing  objects  and  providing 
new  methods  entails  little  work  in  Objective-C  (NEXTSTEP)  and  even  less  work  in 
SmallTalk  relative  to  the  X  environment.  In  summation,  the  realization  that  we  can 
modify  the  development  environment  quickly  and  preserve  existing  functionality  al¬ 
lows  us  to  target  a  higher  level  of  functionality  in  the  Command  Editor  for  NEXT¬ 
STEP. 


4.2  Motif  Menu  Usage 

A  Motif  application  creates  its  menu  system  by  creating  a  form  widget  and  attaching  it 
to  the  application  window.  This  form  widget  is  the  application’s  menu  bar.  The  applica¬ 
tion  then  creates  individual  CascadeButtons  to  populate  the  menu  bar.  A  Motif  Pull- 
DownMenu  is  then  created  and  populated  with  individual  PushButtons  that  represent 
m  "u  cells.  The  PullDownMenu  is  then  associated  with  a  CascadeButton.  Figure  6  il¬ 
lustrates  the  relationships  among  these  widget  classes.  The  code  to  implement  a  menu 
bar  follows  (Figure  7). 
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FIGURE  7  Using  Motif  Menus 

void  iiuiin(ar9C,argv) 
int  argc; 
char  ’argv ( 1 ; 

{ 

Arg  alilOI; 

int  ac; 

Widget  i»enu_bar.  cascade,  fileMenu.  openPB,  closeCB; 

/*  create  the  toplevel  shell  */ 

toplevel  <  XtAppInitlalize(fccontext,  "  .NULL. O.fcac, 
argv, NOLL, NULL, 0) ; 


/•  create  a  form  widget  •/ 
ac=0; 

form=XnCreateFom(toplevel.  'form’ .  al.  ac)  ; 
XtManageChild ( form) ; 


/*  eraata  tha  asaa  bar  •/ 

ac*0; 

MBu  JbaraaaCraataMaoiiBar  ( tons,  ■■anajsar  ■ .  al .  ae )  i 
XtManageChild (manujhar) ; 

/*  attach  tha  menu  bar  to  the  form  •/ 
acaO; 

XtSatArg (al  lac]  .XoNtopAttachment . XmATTACH.FORM) ,-  ac-^-^: 
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» 

XtSetArg (al  [ac> ,  xniNrightAttachment .  xmATTACH_FORM) ;  ac++  ; 

XtSetArg(al [acl . XmNlef tAttachment, XmATTACH_FORM) :  ac**: 

XcSetValues (menu_bar , al , ac) ; 

/•  eraata  tha  CaseadaSutton  */ 

XtSetArg(al (acl .XnNlabelSCring, 

XinStringCreateLtoR(menu_naine,  char_set)  )  ;  ac*+;  . 

eaacada>m;raataCaacadaautton(>anu_bar,Binu_naaa, al, ae) ; 

XtManageChi Id (cascade) ; 

/*  eraata  tha  SulldownManu  ■/ 

f ilaMaattaxacraataSulldownManu (aanu.bar, 'rila', hdll, 0 ) i 

/*  asaoelata  tha  rullSownMaau  with  tha  CascadaButton  */ 

ZtVaSatvaluaa  (eaaeate,  zaasuhNasuId,  fllaManu,  HDU,); 


/*  populata  *Flla'  BulldownManu  */ 

ac  =  0; 

XtSetArg  (al  (ac) ,  XinMlabelString, 

XmStringCreateLtoR ( “Open* , char_set) ) ;  ac**: 

eoaaBBaSBCraataBuahButton ( (llaManu , 'Opan' , al , ac ) r 

ZtltanaeaChlld(opanFB)/  I 

ZtAddCallback(opan*B,XBMaetlwataCallback,opanCB,cllant_data) ; 

XtSatSaaaltlva (opanPB.Tzua) t 

ac  =  0; 

XtSetArg  (al  (ac] .  XniNlabelString. 

XinStringCreateLtoR( "Close* .  char_set) )  ;  ac**: 

eloaaPBaxacraataPttshButton ( f 1 laMaou , 'Close', al,ac}r  ^ 

xtMaaagaChi ld(elosars)i 

XtAddCallbaek ( elesaPB, XaBact IwataCal Ibaek , 
closaCB,ellaac_data) i 

Ztsatsaasitiwa (closaPB,  True) ; 

XtRealizeWidget (toplevel) : 

XtAppHainLoop (context) :  | 

) 

Menu  items  (Open,  Close)  are  displayed  from  top  to  bottom  in  the  order  they  are  aeat- 
ed.  In  fact,  the  PuIldownMcnu  widget  is  actually  a  Motif  RowColumn  widget  with  its 
resources  set  to  act  as  a  pulldown  menu.  While  additional  resources  can  specify  the  ori¬ 
entation  ^vertical  or  horizontal)  of  the  PulldownMenu,  child  widgets  are  always  or-  I 

dered  in  the  sequence  they  are  created.  No  method  is  available  to  insert  a  menu  item 
(PushButton)  in  a  specific  location.  To  allow  the  user  to  add  and  delete  menu  items  at 
runtime,  the  Command  Editor  will  destroy  and  recreate  the  entire  PulldownMenu  wid¬ 
get  with  new  configuration  data.  Though  this  inefficiency  is  incurred  only  when  the 
user  customizes  the  menu  system  and  hence  will  not  affect  the  application’s  perfor¬ 
mance,  we  will  nevertheless  investigate  alternatives  to  recreating  the  PulldownMenu  I 

widget. 

Motif  menus  are  modal  and  do  not  facilitate  drag  and  drop  customization.  Whether 
Popup,  PulIDown,  or  PullRight,  a  "posted”  (visible)  Motif  menu  does  not  allow  the 
user  to  interact  with  the  application  until  the  menu  curtain  is  “unposted.”  The  unpost¬ 
ing  occurs  when  (1)  the  user  selects  a  menu  item  or  (2)  the  user  makes  an  invalid  selec-  . 

tion  outside  the  menu  curtain  altogether.  Motif  does  provide  the  TearOff  menu, 
however,  which  remains  posted  even  after  the  user  makes  a  selection.  TearOff  menus 
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mimic  the  NEXTSTEP  style  of  menus  by  remaining  on  the  screen  throughout  the  ap¬ 
plication’s  runtime. 

We  can  accomidish  drag  and  drop  customization  of  Motif  menus  in  three  ways. 

•  TeaiOff  Menus  -  This  method  requires  the  developer  to  designate  all  customi¬ 
zable  noenus  as  TeaiOff  menus  and  similarly  requires  the  user  to  tear  off 
menu  curtains  before  attempting  customization.  The  user  can  drag  a  new 
menu  item  (or  submenu  item)  Erectly  onto  the  posted  TeaiOff  menu.  Con¬ 
versely,  the  user  can  <Control>  drag  to  remove  menu  items.  This  functional¬ 
ity  poses  several  challenges.  The  first  is  simply  subclassing  the  Motif  TeaiOff 
menu  to  add  DND  logic.  The  second  challenge  involves  updating  a  modified 
TearOff  menu  to  reflect  additions  and  deletions.  An  additional  challenge  is 
the  communication  between  the  TeaiOff  menu  and  ita  PulldownMenu  repre¬ 
sentative  in  the  ai^licuion  menu  bar;  the  PulldownMenu  must  reflect  any  ad¬ 
ditions  or  deletions  made  to  the  TearOff  menu. 

•  Posted  Menus  -  This  method  allows  the  user  to  drag  a  menu  item  onto  the 
menu  bar.  While  continuing  the  drag,  the  user  can  activate  a  drag-srnsitive 
cascade  button  in  the  menu  bar,  which  pulls  down  its  menu  cuitain.  The  user 
can  then  drag  into  the  menu  curtain,  position  the  drag  icon,  and  drop  the 
menu  item  to  be  added.  Once  again,  subclassing  the  Motif  menu  (now  Pull¬ 
downMenu)  to  add  DND  logic  is  key.  The  CascadeButtons  will  also  need  to 
be  sensitive  to  DND. 

•  Special  Purpose  Shells  -  This  method  allows  the  user  to  drag  a  menu  item 
onto  a  representation  of  the  menu  system.  This  representation,  possibly  imple¬ 
mented  as  a  hierarchical  brc  vser,  will  detect  the  drop,  calculate  the  mouse  po¬ 
sition  relative  to  its  displayed  menu  items,  and  add  the  menu  item  to  the 
actual  menu  system.  This  method  involves  developing  a  hierarchical  browser 
cap’>ble  of  DND. 

Our  design  will  adopt  the  last  method,  the  motivations  for  which  include  reusability  of 
the  drag-initiating  hierarchical  browser  developed  to  display  the  developer’s  full  set  of 
commands  and  simplicity  of  implementation.  This  browser  is  necessary  in  all  three 
methods.  The  development  of  the  DND  hierarchical  browser  will  itself  entail  widget 
subclassing  and  allow  us  to  assess  the  feasibility  of  the  other  two  methods. 

4,3  Motif  Mtnu  Implomontation 

Our  concern  for  the  difficulty  of  the  first  two  drag  and  drop  methods  described  above 
stems  from  the  opacity  of  Motifs  implementation  of  menus.  The  following  is  an  ex¬ 
cerpt  from  Volume  6  of  the  O’Reilly  and  Associates  “X  Window  System”  series.  Motif 
Programminz  Manual: 

**Motif  does  not  use  Xt’s  normal  methods  for  creating  and  managing 
menus.  In  fact,  you  cannot  use  the  standard  Xt  methods  for  popup 
menu  creation  or  management  without  virtually  reimplementing  the 
Motif  menu  design...lnstead,  the  Motif  toolkit  abstracts  the  menu  cre¬ 
ation  and  management  process  into  generic  routines  that  make  the 
menu  opaque  to  the  programmer;  the  internal  implementation  is  irrele¬ 
vant." 
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This  statement  implies  that  we  may  not  be  able  to  subclass  Motif  menu  components 
such  as  PullDownMenu  and  add  functionality  via  Xt  routines.  For  instance,  subclass¬ 
ing  the  PullDownMenu  and  adding  DND  logic  may  prohibit  the  attachment  of  the  al¬ 
tered  PullDownMenu  to  the  CascadeButton  in  the  menu  bar  The  feasibility  of 
implementing  Motif  menus  with  augmented  widgets  is  unclear. 

5.0  Implementation  Path 

5.1  Initial  Development  Stage 

This  stage  of  development  targets  a  fully  functional  Command  Editor  package  that  al-  ^ 

lows  the  end-user  to  customize  menus  through  modal  dialog  boxes.  We  begin  by  imple¬ 
menting  the  underlying  logic  of  the  package  and  conclude  by  developing  the  graphical 
tools  for  the  end-user  and  developer. 

5.1.1  Underlying  Logic 

The  central  module  responsible  for  storing  the  developer’s  configuration  of  commands  ^ 

and  processing  the  end-user’s  customizations  is  the  CEController.  This  unit  maintains 
two  hierarchical  structures:  a  list  of  commands  composed  by  the  developer  and  another 
list  representing  the  application’s  current  menu  configuration.  The  CEController  pro¬ 
vides  an  interface  through  which  these  lists  are  composed,  traversed,  and  manipulated. 

In  this  initial  phase,  the  CEController  also  mainta’ns  the  list  of  Command  Tool  But¬ 
tons  available  to  the  user  for  customization  (Figure  8).  * 

In  the  process  of  realizing  the  CEController,  we  must  first  define  the  atomic  unit  that 
represents  a  command.  The  CEMenuCell  from  our  NEXTSTEP  implementation  will 
be  used  in  this  migration  of  the  Command  Editor  to  X  and  Motif,  with  slight  modifica¬ 
tion.  While  the  NEXTSTEP  CEMenuCell  embodied  a  “menu  item”  object,  complete 
with  PushButton  functionality,  the  Motif  equivalent  will  be  implemented  as  a  structure  i 

instead  of  a  subclassed  widget.  Widgets  are  created  relative  to  some  parent  widget  and 
this  relationship  dictates  the  placement  of  the  child  widget  on  the  screen.  The  CEMe¬ 
nuCell  structure  will  contain  information  as  to  the  title,  mnemonic,  accelerator  key, 
drag  icon,  default  status,  reconfigurability,  and  activation  callback  of  the  command. 

The  CEController  will  parse  the  CEMenuCell  structure  to  create  the  apprqiriate 

PushButton  in  the  applicaticm’s  menu  structure.  I 

The  hierarchy  of  CEMenuCclls  and  the  CEMenuCells  themselves  will  be  stored  in  a 
directed  acyclic  graph  (DAG).  There  are  two  such  lists:  the  CECommandDAG,  which 
stores  the  developer’s  composition  of  the  full  set  of  commands  available  to  the  end- 
user,  and  the  CEMenuDAG.  which  mirrors  the  current  menu  configuration.  The  CE¬ 
Controller  will  provide  the  interfaces  to  its  DAGs  to  the  developer  and  other  compo-  ^ 

nents  of  the  Command  Editor. 

The  CEController  will  provide  the  developer  with  interfaces  to  its  CECommand¬ 
DAG  and  CEMenuDAG.  These  interfaces  make  possible  the  composition  and  configu¬ 
ration  of  both  DAGs  without  the  CECommandComposer  discussed  in  subsequent 
sections. 
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The  CECommandBrowser,  which  allows  the  user  to  traverse  and  select  from  the  full 
set  of  commands  available,  will  use  a  subset  of  the  developer’s  interface  to  the  CE- 
CommandOAG. 

Lastly,  the  CEController  will  provide  to  the  CEMenuConfigurator  an  interface 
through  which  the  application  menu  structure  is  customized  at  runtime.  Each  customi¬ 
zation  call  in  this  interface  will  modify  the  CEMenuDAG  and,  in  addition,  make  the  I 

appropriate  Motif  calls  to  put  the  customization  into  effect. 


FIGURE  8  The  Command  Editor  for  X  and  Motif;  The  Underlying  Logic 
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5.1.2  The  Hierarchical  Browser 

Despite  the  plethora  of  widgets  provided  by  X  and  Motif,  we  are  unaware  of  any  wid¬ 
get  that  facilitates  the  display  and  manipulation  of  a  hierarchical  structure.  Ideally, 
such  a  widget  would  operate  on  a  generic  datatype — a  tree  of  items — and  only  require 
that  the  tree  implement  a  small  set  of  functions,  namely  a  display  function  and  some 
traversal  routines.  Such  a  widget  will  allow  graphical  traversal  of  the  tree  and  selection 
of  tree  nodes.  The  Motif  FileSelectionDialog  fulfills  the  desired  functionality  for  a 
Unix  file  system.  Whether  this  canned  widget  can  be  permuted  to  display  and  traverse 
a  generic  tree  structure  is  unclear.  We  will  investigate  this  possibility  while  actively 
searching  the  Internet  and  other  sources  for  a  generic  hierarchical  browser  widget.  If 
both  efforts  are  unfruitful,  we  will  develop  the  browser  from  a  collection  of  Motif  wid¬ 
gets. 
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Once  the  generic  hierarchical  Ix'owser  is  available,  we  will  integrate  the  browser  with  the 
CEControIler  and  its  DAGs,  The  browser  will  interact  with  the  CEController  through 
the  interface  defined  for  the  DAGs  to  display  and  compose  CEMenuCelb.  By  the  com¬ 
pletion  of  this  step,  the  generic  browser  has  effectively  been  subclassed  into  the  CE- 
MenuTYeeBrowser. 

5.1.3  End-user  Tools 

The  CEMenulY^Browser  will  be  instantiated  and  incorporated  into  dialog  boxes  to 
provide  configuration  tools  to  the  end-user.  The  CECommandBrowser  dialog  box  al¬ 
lows  the  end-user  to  traverse  and  select  from  the  full  set  of  commands  configured  by 
the  developer.  The  CEMenuConflgurator  dialog  box  will  display  the  current  applica¬ 
tion  menu  structure  and  allow  the  user  to  modify  this  menu  structure’s  configuration. 
The  CEMenuConflgurator,  in  particular,  will  need  to  communicate  user  customiza- 
tions  to  the  CEController,  which,  in  turn,  will  manipulate  the  application  menu  struc¬ 
ture  to  reflect  the  user’s  modifications. 


I 


I 


» 


» 
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5.1.4  Developer  Tools  ^ 

The  CEMenulVeeBrowser  will  be  incorporated  into  a  dialog  that  facilitates  the  devel¬ 
oper’s  composition  of  the  full  set  of  commands  available  to  the  end-user  at  runtime. 

This  dialog,  the  CECommandComposer,  also  allows  the  developer  to  configure  the 
default  menu  structure  that  is  initially  displayed  in  the  absence  of  user  customization. 

The  CECommandComposer  will  write  the  command  hierarchy  in  a  format  palatable 
to  the  CEController.  We  will  also  develop  an  ingest  procedure  by  which  the  CECon-  • 

trailer  can  (1)  reconstruct  the  full  set  of  commands  at  nrntime  and  (2)  reconstruct  the 
application  menu  structure  at  runtime. 

5.1.5  A  Special  Case 

The  CECommandlbolButton  is  an  interesting  implementation  departure  for  the  Com-  | 

mand  Editor.  While  the  menu  system  relies  on  the  CEController  to  update  its  configu¬ 
ration  and  resources,  the  CEC^mmandToolButton  handles  the  customization  itself. 

When  the  user  selects  the  ‘Tools”  item  in  the  application  “Customize”  menu,  the  call¬ 
back  invoked  will  set  all  registered  CECommandToolButtons  to  “Customize  Tools” 
mode.  The  CECommandToolButtons  will  register  a  special  callback  to  bring  forth 
the  CECommandBrowser  when  activated.  The  user  then  selects  the  target  CECom-  g 

mandTbolButton  and  the  CECommandBrowser  becomes  visible.  The  user  then  se- 
lecu  the  desired  command  and  the  targeted  CECommandlbolButton  registers  the 
new  resource  data  unto  itself.  This  mechanism  is  an  elaboration  of  callback  chaining. 

The  only  dependency  on  the  CEController  occurs  in  the  initial  stage  of  obtaining  the 
full  list  of  registered  CECommandlbolButlons.  This  is  the  motivation  for  the  require¬ 
ment  that  the  developer  register  all  CECommandToolButtons  with  the  Commmd  Edi-  9 

tor. 


5.2  Adding  Drag  and  Drop 

This  stage  of  our  development  effort  targets  the  DND  capability  of  Motif  by  augment¬ 
ing  the  components  developed  in  the  previous  stage.  To  add  the  functionality  discussed 
in  Section  2. 1 ,  the  following  tasks  need  to  be  completed. 
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•  The  CEConunandBrowser  needs  to  be  cognizant  of  drag  starts  and  capable 
of  transferring  the  ctvrect  data  to  the  drop  site.  The  OSF/Motif  Programmer’s 
Guide  outlines  the  procedures  necessary  for  dragging.  Specifically,  button 
translations  will  be  added  to  allow  the  user  to  use  a  particular  mouse  button  to 
initiate  a  drag.  We  also  need  to  set  the  drag  icon  to  indicate  the  type  of  data 
the  drag  represents.  Hnally,  the  drag  start  site  needs  to  format  and  transfer  the 
drag  data  to  the  drop  site. 

•  The  CEMenuConflgurator  needs  to  process  drag  drops  and  corrununicate 
configuration  changes  to  the  CEControUer.  To  do  this,  the  CEMenuConfigu- 
rator  must  register  itself  as  a  valid  drop  site  for  the  CEMcnuCell  data  type, 
register  the  operations  it  is  capable  of  performing  (COPY,  LINK,  MO^), 
and  implement  the  callbacks  to  process  the  drop.  Likewise,  the  CEMenuCon- 
figurator  will  process  drag  starts  to  allow  the  user  to  remove  menu  items 
from  the  hierarchy. 

•  The  Command  Tool  Button  will  be  implemented  as  a  subclass  of  PushButton 
with  additional  methods  that  allow  the  user  to  drag  a  command  onto  the  but¬ 
ton  and  configure  its  icon  and  callback  procedure  via  the  subsequent  drop. 
The  procedures  to  implement  a  drop-sensitive  PushButton  are  analogous  to 
those  for  the  CEMenuConflgurator.  The  CECommandToolButton,  howev¬ 
er,  will  not  communicate  its  configuration  changes  to  the  CEControUer.  Rath¬ 
er,  it  can  simply  modify  its  own  icon  and  callback  procedure.  By  the 
completion  of  this  stage,  the  developer  will  no  longer  need  to  register  each 
customizable  CECommandToolButton  with  the  CEControUer;  he  can  sim¬ 
ply  instantiate  the  button  and  place  it  anywhere  in  the  application. 


6.0  Questions  and  Impact 


This  section  relates  the  concerns  raised  in  the  section  “Constraints”  to  the  implementa¬ 
tion  path  we  envision.  The  critical  issues,  whose  resolution  will  alter  the  course  of  our 
implementation,  are 

•  the  utility  and  difficulty  of  widget  subclassing, 

•  the  feasibility  of  customizing  Motif  menu  components  while  retaining  stan¬ 
dard  menu  functionality, 

■  the  availability  of  a  hierarchical  browser,  and 

•  the  ease  of  adding  DND  to  a  widget. 

We  have  charted  an  implementation  path  that  minimizes  the  impact  of  the  aforemen¬ 
tioned  issues.  The  only  assumptions  necessary  for  the  success  of  our  development  are 
the  latter  two  issues:  that  a  hierarchical  browser  will  be  available  and  that  DND  logic 
can  be  integrated  into  a  widget  with  relative  ease.  The  first  two  issues,  should  they  be 
resolved  favorably,  will  redirect  our  development  effort  to  (H’ovide  improved  function¬ 
ality  to  the  user.  In  short,  our  implementation  path  prepares  for  the  worst  and  targets 
Uk  maximum  functionality  given  that  assumption. 

Aside  from  the  critical  issues,  a  few  considerations  remain  for  later  revisions  of  our 
package.  We  have  purposefully  omitted  a  few  issues  in  the  previous  discussions  that 
detract  from  the  intent  of  our  design.  One  such  issue  is  the  Motif  PushButton’s  com- 
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plete  set  of  resources — class  resources  as  well  as  inherited  resources.  We  have  limited 
our  discussions  of  customizing  a  menu  item  and  CECommandTooIBotton  to  title, 
callbacks,  icons,  mnemonics,  and  accelerator  keys.  We  could  just  as  easily  inctxporate 
the  full  set  PushButton  resources.  Fm  instance,  a  PushButton  that  senses  multiple 
clicks  can  be  customized  to  perform  a  specific  action  on  a  (iouble-click.  A  concern  is 
raised  on  the  behalf  of  the  CECmitroller,  which  affects  the  user’s  customizations  by 
overriding  an  existing  PushButton’s  resources.  The  CEControUer  must  now  modify 
all  resources  to  ensure  that  a  menu  item  does  not  exhibit  the  mixed  behavior  indicative 
of  two  dissimilar  resource  sets. 

Motif  also  allows  PopUp  menus.  We  have  not  determined  what  customizing  functional¬ 
ity  to  provide  for  PopUp  menus.  Customizing  Pc^Up  menus  would  most  likely  be 
done  via  a  representation  of  the  PqjUp  menu  with  drag  and  drop. 

We  have  not  incorporated  multiple  states  in  this  discussion  of  the  Command  Editor.  Im¬ 
plementation  of  multiple  states  entails  keeping  a  set  of  callbacks  and  titles  with  each 
CEMenuCell.  This,  as  well  as  the  previously  mentioned  features,  can  be  added  in  lat¬ 
er  revisions  of  our  package. 
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